Typical examples of an assembly are: a complete car, an airplane, a ship, including mechanical and electrical equipment, the inside and/or the outside of a car body structure. The aim of the design of such an assembly is to provide the engineer with a virtual occurrence of the future product in order to ease investigations and alternatives.
When designing a new assembly of objects, the designer typically works with a PLM/CAD system (i.e. Product LifeCycle Management/Computer Aided Design system). The system contains a database of reference objects, such as parts or assemblies of parts stored beforehand (also possibly created and stored while designing the new assembly).
An assembly is modeled by a reuse graph. A reuse graph (or “re-use” graph) is a labeled directed acyclic graph which captures the reuse schema underlying the assembly. More specifically, a node of a reuse graph corresponds to a reference object or to an assembly of reference objects. For the sake of convenience, in the following no distinction is made between a node and the object to which it corresponds. An arc of a reuse graph is labelled and represents a “use” of the end node of the arc by the origin node of the arc. In other words, a node of a reuse graph is made of uses, i.e. instances, of its child nodes. Reuse graphs are also known as instance graphs.
An example of a reuse graph is represented by FIG. 1. In this example, node a is made of two uses of node b and one use of node c (i.e. the reference object corresponding to node a is made of two instances of the reference object corresponding to node b and one instance of the reference object corresponding to node c). FIG. 1 also tells that node b is made of two uses of node c.
In order to concretely illustrate how a reuse graph models an assembly, let us consider that node a corresponds to a car, node b to an axle of a car, and node c to a wheel. A car uses two axles (front axle and rear axle), corresponding to arcs u1 and u2. Each axle uses two wheels (left wheel and right wheel), corresponding to arcs u3 and u4. Finally, a car uses another wheel which is not used by any axle (spare wheel), corresponding to arc u5.
As shown by the example of FIG. 1, a characteristic of a reuse graph is that its nodes may be used several times. In other words, and in opposition to a tree graph, nodes of a reuse graph may have several parent nodes. Thus, a reuse graph gathers all the information while avoiding duplication of information.
The reuse graph gathers all the information and allows resource saving during storage. However, it is not user friendly for design. For this reason, an unfolded graph is computed from the reuse graph by exploring all the arcs and duplicating reused nodes. The unfolded graph is consequently always a tree graph (i.e. all nodes except the root node have exactly one parent node). It provides a realistic view of the whole assembly because all occurrences of all objects are visible. Furthermore, the unfolded graph may be viewed as a graphical representation of the assembly and all occurrences of all objects are then displayed at exact positions in space. Unfolded graphs are also known as occurrence graphs.
The unfolded graph corresponding to the reuse graph of FIG. 1 is represented in FIG. 2, to which it is now referred.
In order to take into account objects duplications, indexes ((•,1), (•,2), (•,3), (•,4), (•,5)) are associated to arcs (u1, u2, u3, u4, u5) and nodes (a, b, c) of the unfolded graph. This way each symbol of the unfolded graph, including arcs and nodes, is unique. The unfolded graph is however not persistently stored in the system for two reasons. Firstly, duplicated data take more memory space than the reuse graph. This is particularly an issue when designing complex assemblies. Secondly, updating duplicated data is a difficult and costly process because of the exhaustive scan of all the copies. For this reason, only the reuse graph is persistently stored in the system.
Consequently, when unfolding a reuse graph; for example when a designer wants to edit an assembly, indexes are generated on the fly in order to distinguish occurrences of the same reference object during the edition time. Closing and opening again the same assembly will generate different indexes. Furthermore, two designers may want to edit the same assembly at the same time and generate different indexes.
An assembly is further modeled by relations having tuples (i.e. an ordered set of objects within the relations). A typical relation is the distance between two objects. Creating a tuple of such a relation in the concrete illustration provided above in reference to FIG. 1 consists for example in defining a distance between two wheels.
Relations are captured through the unfolded graph. Suppose that the designer creates for the distance relation a tuple having the objects (c,1) and (c, 5) in the example of FIG. 1. They are both a use of reference object c. As explained previously, indexes (•, 1) and (•,5) are not stored persistently. Thus it is not possible to persistently store “distance between (c,1) and (c,5)”. Doing so, the system would not find the occurrences of object c to put in relation or may find incorrect occurrences after a close-and-open sequence because there are five occurrences of object c and new indexes are generated each time the reuse graph is unfolded. Moreover, when two users release their design, relations must be stored together with the reuse graph in such a way that, when reading the assembly again, relations of both users are available.
The consequence of these constraints is that a relation must be encoded with symbols of the reuse graph, so that the relation may be stored persistently. The state of the art solution is to name nodes of the unfolded graph using the path of arcs from the root node. For example, node (c,1) is reachable from the root node (a,1) by arcs (u1,1) and (u3,1), so its path is defined by the concatenation of arc symbols (u1,1)(u3,1). Then, the name of node (c,1) is obtained from the path (u1,1)(u3,1) by keeping persistent symbols only, which yields u1u3. A similar reasoning for (c,5) yields u2u3. Finally, the relation between nodes (c,1) and (c,5) is persistently stored as “relation between u1u3 and u2u3”. Notice that u1u3 and u2u3 define unique paths in the unfolded graph even after changing all indexes. This property guarantees the persistency of the relation after a close-and-open sequence. It also guarantees concurrent creation of relations on the same assembly.
Opening an assembly is performed through two steps. First step is to compute the unfolded graph from the reuse graph. Second step is to find, for each relation and each tuple of the relation, which nodes of the unfolded graph are in the tuple. The algorithm searches in the unfolded graph the path of arcs corresponding to the paths of reuse arcs stored in the tuple. This step is called “update relations”. A tuple of a relation that cannot be connected to any node of the unfolded graph (no path matching) is said to be “broken”.
A tuple may be broken when the reuse graph modeling an assembly is edited. FIGS. 3-5 illustrate one circumstance where editing a reuse graph leads to a broken tuple.
FIG. 3 is a representation of an unfolded graph of the assembly modeled by the reuse graph of FIG. 1, and further modeled by a relation named Connect having one tuple. A tuple of the relation Connect is a couple of objects mechanically connected. In the example of FIG. 3, the tuple may be coded on non persistent occurrence symbols as Connect[(c,1),(c,5)], on non persistent path symbols as Connect[(u1,1)(u3,1),(u2,1)(u3,1)], and on persistent path symbols as Connect[u1u3,u2u3]
This tuple may be broken after a change in the reuse graph of FIG. 1. Tuples are coded using paths of arcs of the reuse graph. If this graph is edited, (add, delete or reroute arcs, add, delete nodes, etc.) some paths may not exist any more and tuples coded with these paths are broken. Consequently, rework is needed from the designer to reconnect tuples. For example, suppose that the designer edits the reuse graph in FIG. 1 by adding a new reference product d between a and b, as represented in FIG. 4.
FIG. 5 represents the unfolded edited graph corresponding to the edited reuse graph of FIG. 4. The tuple Connect[u1u3,u2u3] is broken because the path u1u3 does not identify any node of the unfolded graph in FIG. 5. Notice that the path u2u3 (defined in the context of FIG. 3) identifies node (c, 7), as expected. Indexes of FIG. 3 are changed to simulate a close-and-open sequence after the reuse graph edition.
In the case a tuple is broken, design is tedious because the designer has to reconnect tuples manually. It is thus an aim of the invention to provide a solution for automatically repairing broken tuples in order to facilitate design.